Networks are well known and are becoming increasingly popular as consumers connect computers and various digital devices, such as game stations, set-top boxes, digital audio/video equipment, and computer peripherals. Computers and electronic devices (hereinafter also referred to as nodes) in a network have a processor and transceiver configured to generate and receive data on the network. Nodes on a network intercommunicate via buses. Examples of popular buses used to link nodes are the universal serial bus (USB) and the high-speed serial bus known as Firewire or “1394.”
Some digital devices such as Sony PlayStation2™ use an input/output processor (IOP), which has an integrated transceiver for generating and receiving data on a network. IOPs are well known. An IOP typically undergoes testing during production to determine whether it meets certain device/chip specifications. An IOP may also undergo testing if it is returned after failure in the field. A returned IOP is also referred to as a return material authorization (RMA) IOP. An RMA IOP is tested to determine what part of the chip failed. While field failures are generally undesirable, field failures can provide useful feedback. For example, recommendations can be made to design engineers for future design revisions. Recommendations can also be made to test engineers and production engineers for modifying the automatic test equipment (ATE) software to improve the screening of IOP chips. Such recommendations can result in a smaller defects per million (DPM) number for the IOP chips delivered to a customer.
Failure analysis of RMA IOPs involves manual testing of an IOP via a 1394 or a USB. A user types test commands into a computer. The test commands are sent to the RMA IOP, which sends a response back to the computer. The user can then analyze the response to possibly determine why the RMA failed in the field.
A problem with manual testing is that it can become boring for the user to manually perform the testing. Furthermore, manual testing introduces more room for human error. For example, a person testing a chip (also referred to as a device under test (DUT)) looks at individual bits from the results from the DUT test and compares those bits to bits from results from a reference/good chip. This can get tedious and when numerous registers and other components of a chip are being tested. Furthermore, the test time for manual testing is typically 2 days long. Consequently, misreading of the results can occur.
FIG. 1 is a block diagram of a conventional test system 50 for testing nodes in a network 52, which includes a plurality of nodes 54 and 56 and a bus 58 that couples the nodes 54 and 56. The node 54 is a DUT IOP board and includes a DUT IOP 60 and ports 62 and 64. The node 56 is a reference IOP board and includes a reference IOP 70 and a port 72. The bus 58, which is a 1394 bus, connects the nodes 54 and 56 at their ports 62 and 72. The test system 50 includes a network control computer 80, which has a communications port 82. The bus 66 can be connected to the communications port 82 to couple the network control computer 80 to the node 54 at the port 64. During the testing of the DUT IOP 60, a user sends a test command packet, which includes test command data from the network control computer 80 to the node 54 through the bus 66 where the received test command packet is parsed to determine the kind of 1394 packets to generate. Information that is parsed includes the packet size and type, data content and address, speed, source node, and destination node. The 1394 packets are generated by node 54. Command response data is typically sent back to the network control computer 80 from either the DUT IOP 60 or the reference IOP 70 or both.
A problem with this method is that the buses 58 and 66 are assumed to be functioning properly. This would be expected since the packet containing the test command data is assumed to have been transmitted correctly and received correctly since every node on a 1394 bus sees a transmitted packet. The problem, however, is that test command data may become partially or even completely changed. Also, data within the test command packet may become corrupted. Also, erroneous packets may be generated, etc. Furthermore, even though there may not be any problems with 1394 bus alone, these problems may be caused by incompatibility where devices in the physical layer of the network may have compatibility problems with the 1394 bus.
Accordingly, what is needed is a reliable and complete test that decreases the chances of human error and/or bus errors during testing. The present invention addresses such a need.